\chapter{Zastosowane technologie}
\label{chap:zastosowane_technologie}
 W~tym rozdziale opisane są technologie wykorzystane podczas implementacji systemu ze szczególnym wyróżnieniem tych aspektów, które zostały wykorzystane podczas implementacji aplikacji budżetu domowego. Rozdział zawiera także uzasadnienie wyboru każdej z użytych technologii.
 
  \section{GWT}
  
Google Web Toolkit (GWT) jest platformą o otwartym kodzie źródłowym  pozwalającą programistom na tworzenie i optymalizację aplikacji internetowych w języku Java bez kompleksowej znajomości języka JavaScript i różnic pomiędzy przeglądarkami. Technologia jest obecnie używana przez tysiące programistów na całym świecie. 

    \subsection{Architektura aplikacji internetowej}
    Projekt aplikacji internetowej GWT składa się z części klienckiej i serwerowej\cite{GWTLink}. Część kliencka podczas kompilacji jest konwertowana za pomocą kompilatora skrośnego do równoważnego kodu w języku Java Script – formy obsługiwanej przez przeglądarki internetowe. Podczas ładowania strony część kliencka ładowana jest w całości do pamięci przeglądarki. Podejście to eliminuje każdorazowe przeładowanie całej strony przy aktualizacji pojedynczych elementów widoku. Część serwerowa zostaje skompilowana przez standardowy kompilator Javy. 

GWT to zestaw narzędzi i bibliotek na które składa się między innymi biblioteka zawierająca równoważne klasy pakietów JRE(java.lang, java.lang. annotation, java.util, java.io, java.sql), biblioteka komponentów interfejsu użytkownika oraz kompilator skrośny języka Java do JavaScrpit.

    \subsection{Tryby pracy}    
    
Czas kompilacji projektu GWT do postaci JavaScript jest zależny od zadeklarowanych parametrów: uwzględnionych typów przeglądarek internetowych i wersji językowych. Jednak nawet przy deklaracji jednego języka i jednego typu przeglądarki trwa on na tyle długo, że wysoce nieefektywne byłoby każdorazowe kompilowanie po wprowadzeniu zmiany w czasie implementacji programu.
   
W celu przyspieszenia tworzenia aplikacji GWT udostępnia tryb  deweloperski. Tryb ten zakłada rezygnację z wielokrotnych kompilacji do języka JavaScript poprzez wykorzystanie wtyczek do przeglądarek internetowych. Podczas pracy w trybie deweloperskim wirtualna maszyna Javy tworzy kod aplikacji jako kod bajtowy, który następnie jest interpretowany przez zainstalowaną w przeglądarce wtyczkę udostępnioną przez GWT i wyświetlany jako standardowa strona internetowa. Dzięki temu podejściu możliwe jest debugowanie (odpluskwianie) zarówno strony klienckiej jak i serwerowej. Tryb deweloperski umożliwia szybkie i proste tworzenie aplikacji internetowych. Kompilacja projektu niezbędna jest jedynie wtedy, gdy chcemy wdrożyć gotową aplikację. 

    \subsection{Komunikacja z warstwą serwerową}


Aplikacje AJAX\footnote{AJAX --- asynchroniczny JavaScript i XML \ang{Asynchronous JavaScript and XML}}  nie wymagają pobierania całych stron HTML w trakcie ich działania. Jednak jako aplikacje klient-serwer mogą żądać udostępnienia danych z serwera. RPC \footnote{RPC --- zdalne wywołanie procedury \ang{Remote Procedure Call}}jest mechanizmem interakcji z serwerem, który umożliwia prostą wymianę danych pomiędzy warstwą serwerową i kliencką poprzez protokół HTTP.  

    Platforma GWT nie narzuca sposobu komunikacji z serwerem, jednak udostępnia własną implementację protokołu RPC - GWT-RPC \cite{GWT}. Jest to podstawowy sposób komunikacji klient-serwer w projekcie wykorzystującym GWT. Umożliwia on tworzenie żądań do serwera bez konieczności troszczenia się o serializację obiektów.
GWT-RPC w wywoływaniu prostych akcji jest bardzo efektywne, mimo to implementacja rozbudowanej warstwy pobierania danych jest już dość trudna. Problem leży w tym, że mechanizm GWT nie dopuszcza serializacji obiektów encji wybieranych wprost z bazy danych, które zawierają dowiązania do innych obiektów encji będących z nimi w relacji. W praktyce sprowadza się to do tego, że nie można stosować mapowań relacji typu „lazy”(leniwe pobieranie - mechanizm umożliwiający pobranie danych z bazy dopiero w momencie, gdy będą one faktycznie potrzebne), gdyż informacje o relacjach przechowywane w obiektach encji nie mogą być zserializowane i przesłane do strony klienckiej. Sposoby rozwiązania tego problemu są różne, aczkolwiek żaden tak naprawdę nie eliminuje jego przyczyny. Jednym z nich jest mechanizm bazujący na przesyłaniu za pomocą RPC obiektów specjalnych klas DTO \footnote{DTO --- obiekt transferujący dane \ang{Data Transfer Object}}, które będą zawierały jedynie niezbędne dla widoku informacje, co oznacza ręczne przepisywanie atrybutów obiektów do klas DTO (rozwiązanie mało wydajne). Istnieją narzędzia, które umożliwiają automatyczną generacje obiektów DTO np. na postawie plików XML, lecz rozwiązanie te także wprowadzają spadek wydajności. Powyższe problemy doprowadziły do rezygnacji z użycia standardowego w GWT podejścia do komunikacji z serwerem w aplikacji budżetu domowego. Ostatecznie w aplikacji został wprowadzony mechanizm Request Factory.
  

Request Factory jest alternatywnym do GWT-RPC mechanizmem komunikacji z warstwą serwerową. Umożliwia on budowanie aplikacji skupionych na dostarczeniu danych \footnote{CRUD --- utwórz, odczytaj, aktualizuj i usuń \ang{create, read, update and delete}} w przeciwieństwie do GWT-RPC, które celuje w dostarczenie pewnego rodzaju usług. Został stworzony do użycia z standardami mapowania obiektowo-relacyjnego takimi jak JDO czy JPA. Request Factory umożliwia prostą implementację warstwy dostępu do danych zarówno w warstwie klienta, jak i serwera.
  
    \subsection{Interfejs użytkownika}
GWT umożliwia dwie niewykluczające się metody tworzenia interfejsu użytkownika. Pierwsza z nich polega na tworzeniu komponentów bezpośrednio w kodzie Java (analogicznie jak tworzone jest to przy pomocy standardowej biblioteki Swing). 

Drugą metodą jest wykorzystanie mechanizmu UiBinder, który wprowadza deklarowanie widoków w oparciu o język znaczników XML. UiBinder umożliwia również budowanie widoków jako stron HTML, które w sobie zawierają zagnieżdżone komponenty GWT. UiBinder pozwala na wprowadzenie separacji pomiędzy wyglądem interfejsu użytkownika(definicja w języku XML), a jego programowym zachowaniem (definicja w języku Java). 

    \subsection{Uzasadnienie wyboru}
   Specyfikacja programu budżetu domowego zakłada konieczność tworzenia wielu powtarzających się formularzy i częstego odświeżania jedynie pojedynczych elementów widoku, a nie jego całości. Aplikacje AJAX odpowiadają na te wymagania i okazują się efektywniejsze w stosunku do dotychczasowych rozwiązań, dzięki ograniczeniu pobierania całych stron HTML w trakcie ich działania. Technologia GWT, będąc technologią z rodziny AJAX, została wybrana została wybrana do implementacji budżetu domowego z powodu licznych zalet i wyższości wobec innych aktualnie stosowanych rozwiązań.
     
Pierwszą z wykorzystanych zalet GWT jest możliwość pisania w języku JAVA, co pozwala na debugowanie (odpluskwianie) programu. Możliwy staję się więc prosty cykl ,,implementuj-testuj-debuguj'' charakterystyczny dla klasycznych aplikacji uruchamianych na komputerze użytkownika. Tworzenie aplikacji standardowo w języku JavaSrcipt wiązałoby się z trudniejszym wyszukiwaniem błędów i trwałoby dłużej. Jedną z podstawowych zalet języka JavaScript, jest szybka zmiana widoku strony po zmianie w kodzie aplikacji. Efektywna implementacja programu wymaga szybkiej reakcji strony na zmiany. Dzięki trybowi deweloperskiemu cykl pracy ,,zmień - odśwież - zobacz'' jest także dostępny w aplikacjach korzystających z technologii GWT.
	 
Kolejną korzyścią z wykorzystania języka Java jest możliwość wykorzystania standardowych testów JUnit. 
     
Kompilator GWT języka Java do wersji JavaScript tworzy osobny osobny, zoptymalizowany egzemplarz dla każdego typu przeglądarki, uwzględniając różnice między nimi. Ta właściwość wyeliminowała konieczność osobnej implementacji aplikacji budżetu domowego dla różnych przeglądarek. Troska o kompatybilność została przeniesiona z programisty na używaną technologię.
     
Platforma GWT dostarcza ponadto szerokie wsparcie dla internacjonalizacji, możliwość przypisania własnych stylów CSS do elementów widoku GWT, wsparcie dla obsługi historii oraz wiele innych gotowych rozwiązań. Opisane powyżej możliwości udostępnione przez platformę GWT przesądziły o wybraniu tej technologii do implementacji aplikacji do zarządzania budżetu domowego.
    
  \section{Google App Engine(GAE) }
  Google App Engine jest platformą  hostującą aplikacje internetowe w centrach danych Google\cite{GAELink}. Bazuje na zasadzie chmury obliczeniowej - modelu opartym na użytkowaniu usług dostarczonych przez zewnętrzną organizację.
  GAE jako chmura obliczeniowa gwarantuje: 
        \begin{enumerate}
        \item  Uniwersalny dostęp - usługi są dostępne dla użytkowników z każdego miejsca na świecie, używających dowolny sprzęt;
       \item  Skalowalność -  zapewnienia wydajną pracy w miarę zwiększania się rozmiaru przechowywanych danych i popularności aplikacji;
       \item Niezawodność - osiągana poprzez rozproszenie serwerów  udostępniających usługę.
      \end{enumerate}
 
Udostępniona przez platformę baza danych nie jest standardową relacyjną bazą danych. Została ona specjalnie zaprojektowana na potrzeby platformy,  i ze względów wydajnościowych nie udostępnia wszystkich możliwości gwarantowanych przez tradycyjne relacyjne bazy danych.  Zapewnia ona wykonywanie zapytań, sortowanie i transakcje. GAE dostarcza do niej własny silnik zapytań (GQL). Baza danych nie wspiera w zapytaniach między innymi odpowiednika ,,Join'' z języka SQL i operatora nierówności na więcej niż jednym polu.    
        
Korzystanie z platformy GAE wymaga przestrzegania określonych limitów. System wprowadza ograniczenia na czas przetwarzania zapytania, wielkość żądania i odpowiedzi, całkowitą ilość i wielkość plików aplikacji. Platforma uniemożliwia pisanie do systemu plików. W wersji podstawowej korzystanie z platformy jest bezpłatne do momentu wykorzystania określonych limitów. Po ich przekroczeniu aplikacja jest zatrzymywana. 
        
Google App Engine został wybrany do wdrożenia aplikacji budżetu domowego ze względu na łatwą integrację z GWT. W ramach wtyczki firmy Google do edytora kodu Eclipse dostępne jest środowisko lokalne, które symuluje chmurę. W aplikacji budżetu domowego został również użyty dostarczony przez GAE interfejs do identyfikacji użytkowników na podstawie ich konta mailowego w serwisie Gmail.
       
         \section{Java Data Objects (JDO)}
         
   JDO to specyfikacja ORM (mapowania obiektowo-relacyjnego) definiująca  przechowywanie obiektów języka Java w bazie danych w sposób transparentny dla użytkownika \cite{JDO}. Standard definiuje sposoby adnotacji obiektów, pobierania danych przy pomocy zapytań i używania transakcji. Aplikacja korzystająca z implementacji standardu JDO może korzystać z różnego typu baz danych, a także innych repozytoriów danych np. pliki tekstowe i pliki XML. Istnieje wiele różnych implementacji standardu JDO. Platforma Google App Engine udostępnia własną implementacje  dla własnej bazy danych.   
   Zalety użycia standardu JDO:
        \begin{enumerate}
        \item  Przenośność - aplikacje stworzone z użyciem JDO mogą być używane z różnymi implementacjami standardu bez konieczności wprowadzania zmian w kodzie samej aplikacji;
       \item  Transparentny dostęp do bazy danych - specyfikacja eliminuje konieczność znajomości języka zapytań i sposobu komunikacji dla każdego typu bazy danych.
       \item Prostota użycia - standard pozwala użytkownikom skupić się na tworzeniu modelu obiektowego danych, pozostawiają szczegóły zapisu  implementacji JDO.
       \item Wysoka wydajność -  standard zakłada przeniesienie odpowiedzialności tworzenia struktury bazy danych,jej normalizacji i optymalizacji z użytkownika na implementację JDO. 
      \end{enumerate}
   
Wybrana platforma wdrożenia aplikacji budżetu domowego (GAE) udostępnia dostęp do bazy danych poprzez niskopoziomowy interfejs, standard JDO lub standard JPA. Standard JDO został wybrany ze względu na prostotę, uniwersalność i wydajność rozwiązania.